HTTP (HyperText Transfer Protocol) is an application protocol used on top of the TCP/IP (Transmission Control Protocol/Internet Protocol) used to transfer data over the Internet. HTTP is the protocol used to exchange or transfer hypertext. It functions as a request-response protocol in the client-server computing model. Accordingly, to obtain data, a client device sends an HTTP request to a server to obtain this data (or resource) and, in response, the server sends back the data to the client device inside an HTTP response.
It is noted that a web page displayed by a web browser is generally made up of many resources, typically about one hundred elements, also referred to as auxiliary resources. For the sake of illustration, these resources can be HTML (HyperText Markup Language) resources (structuring the content of the page), CSS (Cascading Style Sheets) resources (describing the layout and the style of the content), JavaScript resources (providing dynamic behaviour for the page), image resources and other media or font resources.
In order to display a web page, a client device sends a request to a server for obtaining the main HTML resource. Once it has received this HTML resource, it parses it to identify other resources that are needed to display the web page. Each time a resource is identified, the client sends a corresponding request to the server. Such a parsing process is repeated for each newly requested resource.
For example, upon parsing a main HTML resource, a client device may identify a link to a CSS stylesheet. Upon identification, it requests this stylesheet from the server. Then, when parsing the CSS stylesheet after it has been received, the client device may determine that the stylesheet refers to an image to be used as a background of the web page. Therefore, it will also request this image from the server.
FIG. 1, comprising FIGS. 1a to 1c, illustrates examples of the structure of HTML web pages formed from several resources (i.e. comprising several elements).
As illustrated in FIG. 1a, web page 100 is composed of a main HTML resource denoted H1 that uses a JavaScript resource, denoted JS1, for handling some dynamic content, and that uses a CSS resource, denoted CSS1, for styling the HTML content of H1.
The structure of web page 105 illustrated in FIG. 1b is more complex than the one of web page 100 in that CSS resource CSS1 comprises a sub-resource consisting of an image denoted IMG1, for example an image to be used as the background of the web page 105.
It is to be noted that both web pages 100 and 105 are simplified examples in comparison to actual web pages. However, although the number of resources of actual web pages may be far greater than the number of resources of web pages 100 and 105, the structures of the web pages are very close.
In order to display these web pages, the client device should first obtain HTML resource H1. In response to this request, the server sends the HTML resource to the client device.
Once received, HTML resource H1 is parsed to identify the JS1 and CSS1 resources that are needed to display the web page. After they have been identified, they are requested. Likewise, the IMG1 resource is requested after it is identified when parsing the CSS1 resource.
It is observed here that web pages are often dynamic.
FIG. 1c illustrates an updated version of web page 100 illustrated in FIG. 1a, denoted 100′. As illustrated, the CSS resource is no longer CSS1. It has been replaced by CSS2. Accordingly, when parsing the HTML resource H1, after the web page has been updated, the client device will no longer request the CSS1 resource but will request the CSS2 resource.
HTTP defines several methods for client devices to request data (a method enables a client device to specify the semantic of its request).
Among these methods, the GET method makes it possible for a client device to retrieve a resource from a server. To that end, an identifier of the resource is typically specified by a URL (Uniform Resource Locator) included within the request and possibly by other parameters. The HEAD method is similar to the GET method, however, it aims at obtaining only metadata associated with the identified resource from a server (and not the resource itself).
In order to optimize data communication between servers and client devices, HTTP defines a mechanism allowing a client device or an intermediary component (that may be, in particular, an independent device or a part of a client device) to store resources received from a server in a temporary memory (known as a cache memory). This allows a client device to reuse resources that have been previously received without requesting them again from a server.
For the sake of illustration, since a logo of a company is typically displayed on all the pages of the web site of that company, it is advantageously stored after it has been received so as to be reused to display other pages of the same web site.
The mechanism provided by HTTP for storing resources in cache memories handles various aspects.
According to a first aspect, servers receiving HTTP requests and transmitting data in response to that request are able to specify whether a resource sent in a response to a request can be stored in a cache memory.
For example, a server of a news website may decide that the HTML content of the site's main page is not cacheable (i.e. should not be memorized in a cache memory), as it changes often, whereas the image corresponding to the site's logo is cacheable, as it doesn't change often.
According to a second aspect, servers receiving HTTP requests and transmitting data in response to those requests can specify a validity period for a resource (i.e. how long the resource can be considered as valid) that is to say the period during which the resource stored in a cache memory can be used.
This validity period is referred to as the freshness of the cached resource. A cached resource that can be reused is called fresh and a cached resource that can no longer be reused is called stale.
The server can specify the freshness lifetime of a resource it sends in two ways, either by using an ‘Expires’ header field that defines the date at which the resource contained in the response becomes stale or by using a ‘max-age’ directive that defines the age at which the resource becomes stale.
It is to be noted that a conditional request can be used to validate a stale resource that is still stored in a cache memory. In response to a conditional request, the new version of the resource is sent if it is no longer valid (e.g. if it has been updated) while a predetermined short response is sent if the resource is still valid (e.g. the status code ‘304 Not Modified’, referred to as the 304 status code in the description). There are two ways for identifying the version of a resource: the entity-tag associated with the version by the server and the date of the last modification of the resource by the server.
In order to optimize the transfer of data between a server and a client device, HTTP/2 makes it possible for a server to push data that have not been requested by a client device.
More precisely, a server can send a push promise to a client device to forewarn the latter that the server is intending to push a resource to it. This push promise contains a request to which the pushed resource is a response. Basically, the push promise contains a URI (Uniform Resource Identifier) of the resource the server is intending to push. This enables the client to know what the server is promising. The push promise is made by sending a frame of the PUSH_PROMISE type. After having sent the push promise, the server sends the promised resource in the same way it would send a response corresponding to a client's request.
It is to be noted that a server can only push resources that are in relation to a request sent by a client. More specifically, a PUSH_PROMISE frame identifies both a client request and a resource that will be pushed.
Turning back to FIGS. 1a and 1b, a server can take advantage of HTTP/2 push feature by pushing the auxiliary resources to improve the loading time of the page. In such a case, JS1 and CSS1 resources (FIG. 1a) and JS1, CSS1, and IMG1 resources (FIG. 1b) can be pushed in response to the request directed to H1 resource.
For the sake of illustration, Jetty is an open source Web server that supports the HTTP/2 push feature. To decide which resources to push in response to a request, Jetty records client device requests. Upon receiving a request for a first resource, Jetty monitors for two seconds all the requests coming from the same client device. Any request referring to the first resource (as determined by the ‘Referer’ header field) is assumed to be useful for the client device to process the first resource and is therefore added to the list of resources to be pushed upon receiving a request for the first resource.
It is to be noted that if a caching proxy arranged between a client device and a server is used to reply to a request from this client device, resources should be pushed in a similar way.
In HTTP, a proxy is an intermediary that sits between the client and the server. Depending on its purpose, it may simply watch the HTTP traffic between a client device and a server or it may modify it. Examples of proxies include firewalls, logging proxies, and caching proxies.
A caching proxy makes it possible to decrease the response time to a client device request. To that end, the caching proxy passes responses received from servers to the requesting client devices and stores the responses along with information regarding the corresponding requests. Then, when the same request is received again, the caching proxy is able to directly reply to the client device by retrieving the stored response. This enables the client device to receive the response faster and also to decrease the data traffic between the proxy and the server.
An HTTP caching proxy follows the rules defined by the HTTP Caching mechanism. In particular, when a stored response is stale, it should be validated by a server before being transmitted to a client.
Accordingly, a caching proxy sitting between a client and a server is able to reply to requests of the client in place of the server, decreasing the response time as seen from the client device.
The HTTP/2 push feature also makes it possible to increase the responsiveness viewed from the client device end since a server transmits resources to the client device without waiting for the client device to request them.
However, combining a caching proxy and the HTTP/2 push feature is complex since a server (having the knowledge of which resources are to be pushed in regard to a particular request) is not contacted by a caching proxy to respond to a request when the response is cached. Therefore, in order for a client device to receive pushed resources when the caching proxy is replying to a request, the knowledge of the server has to be transmitted to the caching proxy. This leads to duplicating the knowledge and increasing processing resources of caching proxies.
It should be noted that the HTTP/2 push feature is defined hop-by-hop: there are no constraints in the HTTP/2 specification for establishing a relation between resources pushed by a server to a proxy in response to a given request and resources pushed by the proxy to a client in response to the same request. The proxy may push the same resources, it may push only some of them, or it may push other resources.
Consequently, there is a need for improving the mechanism used by a proxy for pushing resources, in particular for pushing cached resources.